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In model-driven development, an ordered model transformation is a nested set of transformations 
between source and target classes, in which each transformation is governed by its own pre and post- 
conditions, but structurally dependent on its parent. Following the proofs-as-model-transformations 
approach, in this paper we consider a formalisation in Constructive Type Theory of the concepts of 
model and model transformation, and show how the coiTectness proofs of potentially large ordered 
model transformations can be systematically assembled from the proofs of the specifications of their 
parts, making them easier to derive. 



1 Introduction 



In this paper, we outline a mechanism to assemble correctness proofs of model transformations in the 
context of Model Driven Development (MDD). Although MDD is in widespread use, it is essentially an 
informal approach to software development which does not guarantee the correctness of model transfor- 
mations. High-trust solutions are essential if MDD is to be used in safety critical systems and beyond. 

The problem of establishing the correctness of a model transformation is well established, and work 
has been done towards formalising the process using for instance rewriting languages (e.g. Maude H) 
or typed multigraphs |24]. However, these approaches are first-order and do not reflect the higher-order 
nature of the UML-based techniques. The aim of our research is to lay the foundations on which a range 
of certified model transformations might be built, following a line of work that started in ifTTI . where 
the use of constructive type theory to implement model transformations was first discussed. The notion 
of an ordered model transformation was introduced in lITSll . to describe how a complex transformation 
between models, built from a potentially large number of inteiTclated classes, might be derived from the 
specification of a series of mappings between classes, via a partially ordered traversal of the source and 
target models. This paper represents a significant advance on that work in that it a) formally defines 
the specification of an ordered model transformation in type theory, and b) provides a mechanism for 
assembling the proofs of ordered model transformations from their constituent parts. 

In this paper, a model is a Unified Modelling Language (UML) Q class model, and a model trans- 
formation is a function which maps the artefacts of a source model (classes, attributes and relationships) 
onto the artefacts of a target model ifTTl [T2l . UML is a graphical language for specifying the structure 
and behaviour of object oriented systems. It is also a pillar of the Object Management Group's (OMG) 
Model Driven Architecture (MDA) ||6l (a particular brand of MDD), along with the transformation lan- 
guage Query /View/Transform (QVT) |[8l . 

Consider a transformation between two models (see Fig. [T]) in which each object of X is transformed 
into an object of Y , via a precondition at X and a postcondition at Y . In general, the postcondition at Y 
is composed of three components: Data asserts a relation between the attributes of X and Y; Link asserts 
a relation between Y and the class that contains it; and Nest defines the specification (in context) of the 
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Figure 1 : A transformation between classes X and Y, which is subject to a precondition on X and a 
postcondition on X and Y. 



transformation between the classes that X and Y contain (clearly, if Y were a root class, the postcondition 
would not have a Link component, and if Y were a leaf class, the postcondition would not have a Nest 
component). 

While Data components vary significantly between transformations (there is no reason why they 
should be the same), the Link and Nest components are generally quite similar. In fact the only assertion 
that a Link component can make is that Y participates in a relationship with the class that contains it; 
and all that a Nest component can do is pass control of the specification to the classes that X and Y 
contain. This opens up the prospect of removing from users the tedious task of proving Link components 
by hand{^ Of course, this prospect only presents itself by virtue of the ordered nature of the models and 
transformations under consideration, where order is defined by containment. However, such transforma- 
tions are sufficiently common in practice (see, for instance, ifTTI for examples) to make this a worthwhile 
pursuit. 

In this paper, we focus on a particular but nonetheless ubiquitous kind of model transformation, in 
which the source and target models are either partially or totally ordered]^ In particular, based on the 
definitions of model and model transformation given in ifTTl . we show that the proofs of the specifications 
of large ordered model transformations can be systematically assembled from their parts, making them 
easier to derive. Our main contribution is a method to derive coiTcctness proofs for ordered model 
transformations by assembling the proofs of their parts, within constructive type theory. We illustrate the 
method with examples. 

The proofs in this paper have all been implemented in the Coq Proof Assistant IH , see the Coq scripts 

atr 
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The paper is organised as follows: In Section|2] we give a brief introduction to MDA and type theory, 
to try to make the paper self contained. In Section [3j we show how to formalise a model transformation 
(the specification and its coiTcctness proof) in constructive type theory, including the key notion of a 
parametric proof (a proof with a hole over which it is possible to quantify and hence parametrise). We 
then use this idea to formally specify ordered model transformations in general in Section[4] In Section[5j 
there is a concrete example of an assembled proof. Finally, in Section [6} we sum up and discuss future 
developments. 



The proof of an assertion involving a many-valued relationship requires a proof by list induction, and the proof of a chain 
of many-valued relationships, which is not uncommon, requires a nested set of proofs by list induction. 

'Hierarchical models are the rule rather than the exception in industry (the UML metamodel is fundamentally hierarchical), 
where transformations are notable for their size rather than their complexity. 
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2 Preliminaries 

We recall the basic notions of Model Driven Architecture (MDA) and Constructive Type Theory (CTT) 
that are used in the paper. We refer the reader to ifTTI and lfT3l for more details on MDA and CTT, 
respectively. 

2.1 Model Driven Architecture 

The movement away from the machine to a higher level of abstraction began in earnest in the early 1990s, 
with the advent of a number of object-oriented analysis and design methodologies. The most influential, 
in the authors' view, was the one proposed by Shlaer and Mellor in Il2ni22]| . for it played a huge part in 
shaping the MDA a decade later. The aims of the MDA are two-fold: first, that software systems should 
be developed independently of the platforms on which they will eventually run, and second, that they 
should be translated into specific implementations using standard parts, namely model to text and model 
to model transformations. 

In its simplest form, a model transformation takes as input a model, written in a source modelling 
language (IL), and outputs a new model, written in a possibly different target modelling language (OL). 
The transformation should be applicable to any model written in IL, therefore it can be seen as a mapping 
from elements of IL to elements of OL. 

In MDA, both the input and output languages ai^e defined as metamodels within the Meta-Object 
Facility (MOF) |[T5l . Metamodelling in the MOF is usually done according to a four level hierarchy |[T4ll . 
The levels are related by an object-oriented style class/object instantiation relationship: classes at level 
M,+i provide descriptions of objects at level M,-. Roughly speaking, we can think of entities at the Mq 
level as objects representing instances of an Mi UML class. The M2 level is where metamodels are 
defined. Metamodels are collections of instances of the M3 level classes (meta-meta-classes). The M3 
level of the MOF model is used to classify the elements that make up an M2 level metamodel. 

Following ifTTllTSl . in this paper we will consider model transformations as higher-order functional 
programs satisfying certain pre and post conditions. 

2.2 Constructive Type Tlieory 

The type theory below is based on the one proposed by Martin-Lof ifTSl . A type is defined by prescribing 
how its inhabitants are formed. For example, if S is the successor function, then the inhabitants of the 
type Nat are given by 

n: Nat 

0: Nat {Sn):Nat 

If A and B are types, then A f\B, AVE and A — )• B are defined to be types too, where A A B is 
inhabited by a pair of inhabitants of A and B,AVBis inhabited by an inhabitant of A or B, together with 
an indication as to whether it is an inhabitant of A (on the left) or B (on the right), and A — >■ B is inhabited 
by a function from A to B, i.e. 

[a: A] 



a:A b:B a: A b: B b: B 

{a,b):AAB inla:AVB inrb:AVB Xa: A.b: A^B 
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If a is an inhabitant of A, and S(a) is a type whose inhabitants depend on a, then Va: A.B(a) and 
3a: A.B{a) are defined to be types, where \/a: A.B{a) is inhabited by a function that takes A to B{a), 
and 3a : A .B(fl') is inhabited by a pair of inhabitants of A and B(a), i.e. 

[a -.A] 

b:B{a) a: A b: B{a) 

Xa: A.b:\fa: A.B{a) {a, b) : 3a: A .B{a) 

One particular type that we shall meet often in this paper is 

\fa: A.P{a) -^3b: B.Q{a,b) , 

which defines the specification of a transformation that takes a source class A to a target class B, subject to 
precondition P{a) and postcondition Q{a,b). Note that types A AB and A — B are special cases of types 
Vc? : A.B{a) and 3a : A.B{a) where B is independent of a. A term Xa : A.b of type A — B represents a 
function from A to B. 

Application is written simply as juxtaposition: 

t:\fa: A.B{a) s: A 
{t s):B{s) • 

Further, the reduction relation is generated by the j3-rule: 

{Xa: A.t)s — )• t{a H> s} 

The reflexive and transitive closure of the one-step reduction relation — )• is denoted by 

We shall also add to our language a predicate =, which we can use to build dependent types like 
x = 0, where x: Nat. When is substituted for x, the type becomes = 0, which is inhabited by r(0) 
(see |[25l for more details); when 1 is substituted for x, the type becomes 1=0, which is uninhabited. 
Lastly, we shall add the type [E] of lists of elements of type E to our language, and two distinguished 
types Set and Prop, which will be used to classify types. 

3 Type Theory for Model Transformations 

In this section, we formalise UML classes and objects using constructive type theory. 

Definition 1. A UML class C is encoded as a type, that is, an inhabitant of type Set; and a UML object of 
C is encoded as an inhabitant of type C. Furthermore, a base attribute ofC is encoded as an inhabitant 
of type C —7- Ti, where Ti is a ground type, e.g. Nat; and a referential attribute ofC is encoded as an 
inhabitant of type C — t- T2. where T2 is the type of some other UML class or class list. 

We shall assume that every UML class C has a single base attribute Idc of type Nat, and as many 
referential attributes as it needs to encode the relationships in which it participates. For example, if C 
is linked by a one-valued relationship to UML class D, and a many-valued relationship to UML class 
E, then the rule for constructing the inhabitants of C is as follows, where @c denotes an anonymous 
constructor of C. 

n:Nat d: D l:[E] 
@cndl: C 
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PreA Postp 

A\ 



Figure 2: A transformation between A and P. 



The judgement a : A admits several different readings: a is an inhabitant of type A (as above), a is 
a program whose specification is A (which may be that of a model transformation), and a is a proof of 
proposition A (which may be that of a precondition). In the last reading, A is defined to be an inhabitant 
of type Prop, where A is considered to be true if and only if it is inhabited. The relationship between 
propositions and types, which was first discovered by Curry ||5l and later extended by Howard IS, is 
known as the Curry-Howard isomorphism. 

In this paper, we describe a technique to derive proofs of potentially large ordered model transforma- 
tions. To illustrate the ideas underlying this technique, we consider first a simple model transformation, 
where each object of class A (see Fig. [2]) is transformed into an object of class P, subject to a precondition 
Pre A of type A — Prop and a postcondition Postp of type A — )• P — > Prop. |^ The specification of the 
transformation is formalised as a type, i.e. 



\/a: A.PrcAa^^P'- P -Postpap , (1) 



and its proof is given by 



[a:AY [h:Prea]^ 
Hole 
u: Post a p 
{p, u): 3p: P. Post a p 
Xh. {p, u) : Pre a — )• 3p : P.Postap 



(3/) 



2 



(V/)i 



Xa .Xh . {p, u) : ya: A .Prea ^ 3p: P .Post a p ' (2) 

i.e. a function that takes an object a of A and a proof h of PreA and returns as a pair the corresponding 
object p of P and a proof u of Postp a p. There is a hole in the proof above because the transformation 
is under specified. However, given suitable definitions of A, P, PreA and Postp, the hole could be filled 
and the proof completed. Furthermore, given a second transformation with a different set of definitions 
of A, P, PreA and Postp, we could apply the same procedure. However, the proofs would be so similar, 
at least in outline, that it should be possible to capture them all in a parametrised proof, by quantifying 
over all source and target classes, pre and postconditions, and proofs of holes, in the specification of the 
transformation. Based on this idea, we define the following correctness condition. 

Definition 2 (Correct Model Transformation). A correct model transformation from X toY should ensure 
that for each x in X that satisfies the precondition there is ay inY that satisfies the postcondition. This 
is formalised using the following type: 

yx : Set.yy Set.yPre : X Prop .yPost : X -^Y Prop . 
yf-.X^Y.yUole: {y x : X . Pre x Post x {f x)) . 

yx: X .Prex^By: Y .Postxy . (3) 



^ Preconditions serve several purposes. First, to allow a choice of rules in different cases, e.g. by checking that a class is 
a root class, if root classes are transformed by a different rule to non-root classes. Second, to ensure that a postcondition is 
well-defined, e.g. by insisting that x > if the postcondition takes the square root of x. Third, to ensure that only certain source 
elements are transformed, e.g. by checking that a class is persistent, if only persistent classes are mapped to database tables. In 
the first and second cases, we might expect the precondition to contribute to the proof of the postcondition. 
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The proof of (|3]) is little more than two eliminations and a sequence of introductions, i.e. 

[X: Set]^ 
[Y: Set]^ 
[Pre: X Prop]^ 
[Post: X ^ Prop]* 
[f-X^Y]' 

[Hole: {\/x: X .Pre Post X if x))]^ [x: X]'^ ^ ^ 

} \ i^E) i8 

Pre X ^ Post xif x) \h: Prex\ , 

\ . (f \ 

Post x{ fx) 

' {31) 



3y : Y.Postxy 

(V/) 



Pre X — > 3y : Y . Post xy 
Vx: X .Prex ^ 3y: Y .Postxy 



yHole : {yx:X.Prex^ Post x{f x)) .\Jx: X . . 



(V/)6 
- (V/)5 



V/: X Y.^Hole: (Vx: X.Prex Postx (fx)) ... 

yPost :X^Y^ Prop.yf: X->-Y.... ^''^ 
yPre:X^Prop.yPost: X^Y^Prop.... 

yY: Set.yPre: X ^Prop.... ^ ^'^ 

yX: Set.yY: Set.... ^ ' (4) 

The fixed outline shape of the proof is captured by rules (37) to (V/)?, and the variable proof of the 
hole is captured by assumption 6. Furthermore, the function K defined below can easily be shown to 
inhabit (|3). 

K =,if XX.XY.XPre.XPost.Xf.XHole.Xx.Xh.{{fx),u) . (5) 

Note that the arguments X and Y are arbitrary source and target classes; Pre and Post are arbitrary pre 
and postconditions; / is a function that maps source objects to target objects; Hole is a proof of the hole 
(see Q); x is a source object; and h is a proof that the precondition holds on the source object. K returns 
a target object {fx), and a proof u that the postcondition holds on the source and target objects. 

We shall now apply .^T to a particular transformation, i.e. the one between A and P. Let PreA be a 
predicate that holds on all objects of A, and let Postp be a predicate that holds on all objects of A and P 
which have the same base attribute values. Formally, let 

PreA =df Aa.T 

Postp =df Xa.Xp . {Ma a = Idp p) . 



Now, if 

then the proof of the hole is 



/a =df ^a.@p{IdAa) , 

[a: Ay [h:T] 



'Ma'- A ^ Nat^ [a: A 



1 



Ma a : Nat 



r(MA a) : Ma a = Ma a 

^ (— >/J 

Ah . r{MA a) : T — 7- Ma a = Ma a 

Xa . Xh . r{MA a) : V<3 : A . T — )■ Ma a = Ma a 

Xa.Xh. r{MA a) : Va : A . PreA ci — )• Postp a {/a a) 



2 

(V/)i 

(=^/)- 
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Free 



POStQ 



Figure 3: A two-iunged transformation 



Furthermore, if 



HoIca =df .Xh .r{IdAa) , 



then 



KAPPreAPostpfAHoJeA (@a 1) Triv ^ ((@p 1), r{IdA (@a 1))> ■ 

Therefore, @p 1 is the transform of @a 1> and r{IdA {@a 1)) is the term that proves it. 

In the next sections we generalise these ideas to families of ordered model transformations. 

4 Ordered Model Transformations 

In the previous section, we showed how the specification of a small transformation could be abstracted 
into the specification of a family of transformations, by quantifying over all possible source and target 
classes, pre and postconditions and holes. The proof that resulted contained a fixed part, common to all 
members of the family, and a variable part, specific to a particular member. In this section, we extend 
these ideas to ordered model transformations in general. 

There are two kinds of ordered transformations: totally and partially ordered. Informally, a totally 
ordered set of transformations is one that has the shape of a ladder, in which the source and target models 
are the verticals, and the transformations are the rungs. A partially ordered set of transformations has the 
shape of a tree of ladders, in which the branches between nodes are totally ordered transformations. We 
give examples before presenting the formal definitions. 

Consider the two-runged transformation in Fig. [3] in which A is transformed to P subject to condi- 
tions PreA and Postp, and B is transformed to Q subject to conditions Pres and Postq. If an object a of 
A is transformed to an object p of P, then the object Ryaof B is transformed to the object p oi Q. \n 
other words, the transformation of B to 2 is nested within the transformation of A to P. As before, we 
shall define the specification of the transformation as a type, outline its proof, and abstract over classes, 
conditions and holes. The transformation along each rung is similar to the one between A and P earlier. 
However, the transformation between the verticals (relationships) is new. 

The specification of the transformation that is depicted in Figure [3] is formalised as a type as follows 
(for ease of readability, we write one rung per line). 



The transformation along the second rung is nested within the first rung, and has stronger pre and post- 
conditions in virtue of the connectivity constraints placed on objects of B and Q. Note that a third or 
fourth rung would have the same shape as the second rung. 



\/a: A. PreA a^3p 
Wb: B.Pregb A{Ria) =b ^3q 



P . {Postp apA 
Q.Postgbq A{Sip)=q) . 



(6) 
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X ^fx 



R Com 



S 



Rx ^-^S{fx)=f'{Rx) 

Figure 4: The commutative square Com. 

In outline, the proof of Q is 

[a : A] [a: A] 

[b:B] [b:B] 

\PreB b ARia = b] iPres b ARia = b] 

: Holes '■ ConiA 

[a:A\ Postgbq Sip = q 

[Pre A a] [PosIq bqASip = q)[q/q] 

: HoleA '■ Fixed 

Postpap {\fb: B .Presb AR\a = b^ ...)\p/p\ 



{Postpap A\/b: B.Presb AR\a = b . . .)[p / p] 
: Fixed 

Vt? : A . Pre A a^3p: P . Postp ap A . . . 



A/) 



The fixed parts of the proof exist in virtue of the structure of the specification, whereas the variable parts 
exist in virtue of its under- specification. The variable parts are either of the Hole kind, i.e. proofs that 
postconditions are derived from preconditions, or the Corn kind, i.e. proofs that adjacent rungs are linked. 

Quantifying over all variables in (|6]l, including proofs of variable parts, and changing the names of 
bound variables where appropriate, we obtain the specification of an arbitrary two-runged transformation. 

Definition 3 (Two-Runged Model Transformation). An arbitrary two-runged model transformation is 
formalised in constructive type theory by the following type: 

MX : Set. MY : Set .M Pre : X Prop.MPost -.X^Y^ Prop . 
Mf-.X^Y.MHole: {Mx: X .Pre x ^ Post x{f x)) . 
MX' : Set . MY' : Set . MPre : X' ^ Prop . MPost' : X' -^Y' Prop . 
Mf : X' Y'.MHole' : {Mx : X'.Prex Postx {fx')) . 
MR: X -^X' .MS: Y -^Y' . 
MCom : {Mx:X.S (fx) = f (Rx)) . 
Mx: X . Pre x^3y: Y . Postxy A 
Mx' : X'.Pre'x' ARx = x' 3y' : Y' .Post' x y ASy = y' . (7) 

This formalisation is similar to the one in Q except that it also quantifies over Com, i.e. a proof 
that starting from every object x of X {X being the source end of the first rung) and navigating to 
some object y' of Y' (Y' being the target end of the second rung), first via / and S, and then via 7? 
and /', the same y' is obtained. The commutative square, after which Com is named, is shown in 
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Fig. |4] Furthermore, given a proof of Com, it is a trivial matter to prove that the rungs are linked, 

[x:X] [Com:yx:X.S{fx)=f{Rx)] 

S{fx)=f'{Rx) ^ ' -Rx = x'- 

S{fx)=f'.^ 

Property 1. The function that inhabits (|7]l is 

XX Y Pre PostfHoleX' Y' Pre' Post' f Hole' RSComxh.{{f x) , u) 

Proof. Direct, using the typing rules given in Section |2] Note that the first element of the output pair is 
the result of applying the root function / to an arbitrary root object x, reflecting the fact that an ordered 
transformation is essentially a transformation between root classes. □ 

We are now ready to formalise the notion of ordered model transformation. First we consider totally 
ordered transformations, and later we extend the results to partially ordered transformations. 

4.1 Totally Ordered Transformations 

In order to formalise totally ordered model transformations, we will define a dependent type TXY f, 
where T is the type name, and X, Y and / are the parameters on which it depends, i.e. root source class, 
root target class and root function respectively. A totally ordered transformation is an inhabitant of this 
dependent type. The inhabitants of T are defined inductively, in much the same way as Nat, by means of 
a base rule and a step rule. 

Definition 4. (Type TXY f) The type T is defined inductively, with a rule defining the base case and a 
rule defining the inductive step, as follows: 

X:Set Y:Set f:X-^Y 
X' : Set Y' : Set f':X'-^ Y' 
Pre' : X' ^ Prop Post' : X' ^ Y' ^ Prop 
Hole' : Vx' : X' .Pre' x' Post' x' {fx') 
R:X^X' S:Y^Y' Com: Vx: X .f (Rx) = S (fx) 

Tease XYfX'Y'f'Pre' Post' Hole' R S Com :TXYf 

X:Set Y:Set f:X^Y 
X' : Set Y' : Set f':X'^ Y' 
Pre' : X' Prop Post' : X' ^Y' ^ Prop 
Hole' : Vx' : X' .Pre' x' Post' x' [fx') 
R-.X^X' S:Y^Y' Com: \fx: X .f (Rx) = S (fx) 
t': TX'Y'f 

Tstep XYfX'Y'f Pre' Post' Hole' RS Com t':TXYf 



(Th) 



(Th) 



The base rule constructs a transformation of the kind shown in Fig. [5] (left). Note that the root hole 
and root pre and postconditions (to clarify, the root is at the top) are not part of the construction. The step 
rule constructs the successor of a transformation t', of the kind shown in Fig. |5](middle). Again, the root 
hole and root pre and postconditions are not part of the construction. 



72 



Ordered Model Transformations 



X 



X 



R Com 
, Pre' J'_ Post'^, 
Hole' 




B 



C 



fa 

Rl Coin I 
Free fb P^^'Q 

— — — — — 5* 

Holes 
R2 Comi 
Prec fc PostR 



Q 



S7 



Holec 



R 



Figure 5: From left to right: representations of the base and step rules of type T, followed by an inhabitant 
of type T AP fa, namely Iap- 



To construct an inhabitant of T , we first apply the base rule and then repeatedly apply the step rule. 
For example, the transformation Iap in Fig. [5] (right) is constructed as follows: 

tBQ =df TBaseBQ fbCRfcPrec PostR Holec R2S2Com2 , 
tAP =df TstepAPfaBQfhPreBPostQHolesRiSiComitBQ. 

By extension of ([6]), it would be easy to write down the specification of tAp, including the root 
transformation we have so assiduously excluded. However, much more useful would be to write down 
a function that could compute it, not only for tAp but also for every other inhabitant of T XY f as well. 
Such a function is given below. 

Definitions, (Spec) 

Spec:\fX: Set .W : Set .\ff: X -^Y .TXY f {X -^Y Prop) 

Spec XYf {Tease XYfX'Y'f Pre' Post' Hole' R S Com) =d / 
Xx■.X.Xy■.Y.\/x■.X'.Pre'x^x' = Rx^ 3^' : Y' . Post' x'y' Ay' = Sy 

SpecX Y f {Tstep X Y fX' Y' f Pre Post' Hole RSCom t') =df 
Xx-.X.Xy: F.V/: X' .Pre' x Ax = Rx ^ 3y' : Y' .Post' x y' Ay' = Sy A 

SpecX' Y' ft' x'y' . (8) 

Now, the specification of a transformation is an inhabitant of Prop. However, Spec returns an inhab- 
itant of type X — )• y — )• Prop. Why? To allow it to be integrated with the root objects of type X and Y , 
passed down to it by the root transformation. 

In its general form, an ordered model transformation is formalised as follows. 

Definition 6. (Ordered Model Transformation) An ordered model transformation is an inhabitant of 
type 

yX: Set.yY: Set .Vf : X ^ Y .Wt : TXYf. 
yPre : X^Prop. \fPost : X ^Y ^ Prop. 
MHole -.Mx-.X.Prex^ Post x (fx) . 
\fx: X.Prex^By: Y.Postxy ASpecXY ftxy . (9) 
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f 




X' Y' X" 

Figure 6: A representation of the join rule of type T. 

A proof of (|9]) (an inhabitant of the type) has the form: 

IX.XY .Xf.Xt. XPre . XPost . XHole .Xx.Xh. {{fx) ,u) , (10) 

where m is a proof of 

Post X {fx) ASpecXY ftx{fx) . 

According to ( [T0| , if we could construct an inhabitant of type T from suitable values of Hole (a proof 
of the root hole), X and Y (the root classes), / (the root function), and Pre and Post (the root conditions), 
then we could justifiable claim that {{fx), u) is a certified implementation of the transformation, for an 
arbitrary source object x. In other words, constructing a suitable value of t is tantamount to proving the 
specification. 

4.2 Partially Ordered Transformations 

We generalise the construction to take into account the case where transformations are partially ordered. 
Without loss of generality, we assume that a partially ordered transformation can be constructed from 
two ordered transformations, as shown in Fig. [6] Thus, we extend the definition ofTXY f in Definition]?] 
with a join rule, i.e. 

ti: TXYf t2: TXYf ^ 
Tjoinhh'- TXY f 

and extend the definition of Spec (Definition ]5]l with a case for Tjoin, which returns the conjunction of 
the specifications of t\ and t2, i.e. 

Spec XY f {Tjointit2) =df Xx:X.Xy: Y .SpecXY ftixy ASpecXY ft2xy . 

See Fig. ]7]for an example. 

5 Concrete Example 

Consider a transformation between the UML and SQL models in Fig. ]8] in which 

• each model ni is mapped to a schema s of the same name; 

• each class c in m is mapped to a table ? in 5 of the same name, and a primary key column in t of 
the same name; 

• each attribute in c is mapped to a non-primary key column in t of the same name; 

• the mappings are unconditional, i.e. the preconditions always hold. 
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Figure 7: An example of a partially ordered transformation, in which A,B, . . . ,J are the source classes, 
P,Q,. ..,W are the target classes, and A is transformed to P, Bto Q and so on. The transformation (minus 
the root artefacts) is given by where h =df TBase---, ?2 =df TBase---, h =df Tsase---, tm =df 

Tjoin{Tjoinhh)h-, U =df Tstep ■ ■ ■tu3, ?5 =(// Tsase---, ?6 =df Tstep---t4, ?56 =df Tjointi t(,, md tj =df 

Tstep ■ ■ ■ t5(,- The specification of the transformation is given by Spec A P fa t-j. 

The specification of the transformation is given by 

Vm : Model . Pre Model m^3s: Schema . Post schema ms A 
S pec Model Schema f Model tModei-Schema m s , 

where 

tModel-Schema' T Model Schema f Model-Schema ■ 

If 

m =df @ Model 1 [C1,C2,C3] 

C\ =df @ Class 2 [ @ Attribute 5, @ Attribute 6, @ Attribute 7 ] 
C\ =df @Class'i[@ Attribute^] 
C3 =df @Class4[] , 

i.e. a model with 3 classes and 4 attributes, then 

K Model Schema /Model PrcModei Postschema HoleModei m Triv 
reduces to (^i, p), where is given by 

^1 =df @ Schema 1 [?1,?2,?3] 

tl =df @ Table 2 [ @ Column 2 true, @ Column 5 false, @ Column 6 false, @ Column 7 false,] 

tl =df @ Table 3 [ @ Column 3 true, @ Column 8 false ] 

h =df @ Table 4 [@ Column^ true] , 
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Model 
^ model_name: string 
J classes : list Class 

♦ 



* classes 

Class 
£ class_name: string 
£ attributes : list Attribute 

♦ 



* attributes 

Attribute 
J attribute_name: string 



Schema 
A schema_name: string 
^ tables : list Table 



* tables 

Table 

^ table_name: string 
^ columns: list Column 



columns 

Column 
£ column_name: string 
£ is_primary_key: bool 



Figure 8: The UML and SQL models. 



i.e. a schema with 3 tables and 7 columns (3 of which are primary keys), and p is an unspecified proof 
(through lack of space) that is indeed the transform of mi. 



6 Related Work and Conclusions 

A number of authors have attempted to provide a formal understanding of metamodelling and model 
transformations. Ruscio et al. have made some progress towards formalizing the KM3 metamodelling 
language using Abstract State Machines 1201 ; and Rivera and Vallecillo have exploited the class-based 
nature of the Maude specification language to formalize metamodels written in KM3 ifTOll . Further, a 
related algebraic approach is given by Boronat and Meseguer in [2]. More recently, Calegari et al. lO 
proposed a framework for encoding models and metamodels in the Calculus of Inductive Constructions 
(CIC) ll23l [TI. and in doing so showed how parts of the ATL model transformation language ifTOl could be 
expressed in the CIC, including matched rules, helpers and expressions based on the Object Constraint 
Language (OCL) [il6il . 

In this paper, we have shown how to assemble the proof of a potentially large ordered model transfor- 
mation, by decomposing it into a number of smaller proofs which are easier to derive. |^ We focused on a 
particular kind of transformation with uniform characteristics, which we hope to extend to other kinds of 
transformations in the future, although we have already incorporated a number of additional variants into 
the scheme outlined above, including support for many-valued relationships, unmapped source classes 
(of which C is an example in Fig. [7]l and multiple target classes. 

In future work, we will extend the techniques to a larger class of model transformations, by abstract- 
ing over the non-hierarchical parts of models too. One way of achieving this would be to quantify over 
arbitrary propositions in each postcondition so that users could include a non-hierarchical proof frag- 
ment where necessary. To a certain extent, this is already supported because the Data component of a 
postcondition is user-defined and therefore arbitrary. However, another option would be to add a separate 
conjunct to the postcondition. 

^ The reader should note that this approach could never be fully automatised in virtue of the unlimited scope of pre and 
postconditions. However, once the smaller proofs are available, the process of assembling them into a proof of the whole could 
indeed be automatised. 
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Clearly, we do not exclude the possibility of an ordered model being embedded within a larger 
model, like an ordered core with an unordered covering (for example, see Fig. |9]). In fact, our experience 
suggests that the majority of industrial models (which are characterised by their size rather than their 
complexity) are like this, and that the algorithms which transform them invariably perform preorder 
traversals of the ordered cores of the source models. That is not say that every model transformation 
fits this mould. However, it is reasonable to suppose that the lessons learnt from this study may also be 
applicable to other kinds of model transformations. 




Figure 9: An industrial strength model (of executable UML, courtesy of Abstract Solutions Ltd) com- 
prising a strongly ordered core (admittedly, one defined by generalisation — an area for further study — as 
well as containment, and visually apparent only to a subject matter expert) surrounded by an unordered 
covering. 
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